As compute nodes are evolving to include Ethernet/Fabric Switches, the compute functionality associated with compute nodes (such as control of replication, erasure coding, data movement, file cloning, input/output (IO) determinism, etc.) tends to be shifted either to a host/initiator or to target storage devices. If the increased functionality is shifted to a remote host or an administrator, the increased functional load may cause further functional burdening of the remote host and/or administrator, and/or may add computational complexity to target storage devices, thereby increasing costs. Further, target storage devices are normally slave-type devices, and storage requests, such as read/write/administrative requests, are not normally initiated by a slave-type device. Accordingly, a target storage device would need to become a master-type device, similar to a host, in order to act as an initiator for various offload functionalities.
Further, existing non-volatile memory express/non-volatile memory express over fabric (NVMe/NVMe-oF) and/or other storage protocols do not natively and/or cleanly support the concept of a target storage device acting as a master initiator, which limits direct implementation of storage-offload or storage-acceleration functionalities provided by an SSD. Further, if a remote host initiator is a first initiator that is in communication with a first target SSD, another remote host initiator (or another second SSD that supports storage-offload functionalities) is not able to initiate a transfer-type operation or any other communication to the first target SSD until the first target SSD closes the transport function and connection.
Even further, a drive-centered solution to provide increased storage functionality may increase traffic and reduce bandwidth because the remote host control and data traffic interferes with the storage-offload functionality control and data traffic that needs to be shared at the lowest level.